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(57) Abstract: Systems (10) and methods for, inter alia, allowing a remote user (14) to access content, such as data or an executable 
program, on demand from a remoter server. When accessed the content can be delived on demand to the user's remote workstation 
(14) for use by the user. As network resources may vary, the systems described herein further include systems that will monitor 
network resources, and other factors, versus the transfer demands for the content requested by the user. The systems may then 
determine a schedule, or load map (24), for transferring blocks of the contentin a way that efficiently employs the available resources, 
and in a way that provides the user with a user-experience that is similar, or substantially similar, to the user-experience that the user 
would have if the content were stored locally on the user's workstation. 
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SYSTEMS AND. METHODS FOR DELIVERING CONTENT 
OVER A COMPUTER NETWORK 

Technical Field 

This invention relates to methods and systems for delivering content over a 
computer network, including delivering executable and data content that may be 
executed by a remote user in real time. 
Background Art 

Today, ^connectivity over data networks continues to expand Most 
companies today have an internal network, many of which provide high speed data 
delivery to terminals on the netwoik. Additionally, the Internet provides 
interconnectivity between networks, and terminals that located across Ihe globe. 

With the interconnectivity provided by the Internet and other networks, 
systems have been proposed that would allow users to license, on a per use or per 
hour basis, access to a software title such as Microsoft PowerPoint, games or a patent 
docketing software package. In these systems, once the user has been granted access 
to the title, the user can execute the title and employ the software as needed. 
Typically, the appUcation service providers have employed a telnet type architecture 
that has directed the user to employ the user' workstation as a terminal, while 
computing takes place oh a remote processor that has execution access to the selec ted 

title. Alternatively, systems have employed an NFS kind of architecture that joins a 

remote file system into the file systems of the local user. 

Other systems have been proposed that would provide access to executable 

programs that havea (iistributable component architecture. These titles, commonly 

written in Java, may be downloaded piece meal to the remote user, for execution by 

that user on the usefs local terminal. 

Although such component systems can work well, they require that 

applications familiar to the user be re-written into a distributable architecture thar 

allows for easy download over the Internet. Moreover, systems based on telnet 
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technologies or on NFS technologies create problems with burdening the processing 
resources of the remote machine and of security. 
Disclosure of Invention 

The systems and methods of the invention include, inter alia, systems for 
5 allowing a remote user to access content, such as data or an executable program, on 
demand from a remote server for local execution. When accessed the content can be 
delivered on demand to the user's remote workstation for use by the user, providing 
the user with an experience comparable to the user experience provided when 
accessing the content locally. As network resources iniiy vary, the systems described 

10 herein further include systems that will monitor network resources, and other factors, 
versus the transfer demands for the content requested by the user. The systems may 
then determine a schedule and method, or load map, for transferring blocks of the 
content in a way that efficiently employs the available resources, and in a way that 
provides the user with a user-experience that is similar, or substantially similar, to the 

15 user- experience that the user would have if the content were stored locally on the 
user's workstation. 

In one example system, a user at a remote \v6rkstation may request access to 
content such as an executable pirdgram. In response to this request, the system 
transfers blocks of content to the user, where each block contains either data, content 
20 or executable code that the remote workstation cat! einploy to execute the application 
locally. The system may eoh^ 

executable program as the application requires. Optionally, the systems described 
herein may also employ jpredictive threading to preselect requests for content given 
the resource 

25 More specifically, the systems and methods described herein include a profiler 

process that analyzes the content access patte^ wMch can include the disk access or 
memory afccess pattern of an exedudng title and general a load map. This process 
can coUect iiiformation aboiit how the title is accessed from storage as the user 
employs the title. Different user scenarios and choices can be analyzed, and patterns 
; 30 of storage access may be generated. 

'. : -2-'. • 
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To this end, the profiler may observe and analyze the execution of the 
executable content and/or data. During analysis of the content, Ihe file access pattern 
of the executable content may be observed. The profiler may then create a load map 
that is representative of the disk access or other file or memory access that are made 
5 as a user selects among the different options provided by the content. 

The systems described herein may also include a map reader. The map reader 
may be a computer process that interprets the load map created by the profiler and 
creates one or more cache preload requests. The cache preload requests may be 
representative of requests from the client to the remote server for additional 
10 components of the executable title. 

In one embodiment, a cache manager is provided wherein the cache manager 
communicates with the map reader and responds to, /« te r a //a, preload requests from 
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Thus the systems described herein include scheduling processes that more 
efficiently use network resources to facilitate the real-time execution of the program 
More specifically, the systems and methods described herein include a method 
oftransrrittmgdateo^ 

location. The methods may comprise determining a measure of available throughput 
for transnutting data over the network. The membd, mcertam practices, but not all, 
20 may include, i<ientifying information to be transmitted over the network and ' ' 
generating a forward-looking load map of information for a given execution state of 
the program, and based on the load map ^d the execution state, generating an 
iantic^^ v 

throughput and for mamtaining consistent execution ofthe program. In these 
25 methods, the information comprises at least one of data or an executable file. The 
information may be transmitted from a server to a client 

The act of identifying information may include selecting information based on 
the available throughput and the execution state ofthe program at a time of 
selection. Ihforrnation may be packaged, of Wassbciated wim load maps tl^r are 
more suited to one throughput than another, or that are associated with a fee structure 
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that provides one level of service versus another. Additionally and optionally, the 
methods may further include the acts of the client requesting information to be 
transmitted, the client selecting a subset of the information based on the available 
throughput at a time of selection, and the client selecting, for transmission from the 
5 server to the client, information from the subset of the information. In certain other 
practices, the client requesting information to be transmitted, and if the request is 
approved, receiving a key adapted to access the information for transmission from the 
server to the client. Additionally, the methods may include methods wherein the 
forward-looking load map is generated based an axxess pattern for the transmitted 

10 information. Hie access pattern may include the disk access pattern, where the title is 
run under different scenarios or conditions, and the disk access is monitored under 
these conditions. From this activity, a load map that maps out a sequence for 
retrieving data blocks may be generated. 

■ The systems described herein may include a system for transmitting structured 

15 information over a network having an identified available throughput, comprising a 
server providing the information, a client receiving the information from the server, a 
profiler monitoring transmission of the information from the server and generating at 
least one load map based on an analysis of an information access pattern at the seWer, 
a map reader, based on the at least one load map, for interpreting information 

20 contained within a load map and for generating time valued requests to the server 
based on available throughput and informational requirements, and a cache mm 
that merges the information to organize the structured information. The cache 
pMi^ msy further include storage means to store at least the information associated 
>i& apre-16adi operation and may select for margin^ a block of the irifonhation from 

25 the storage means, if the block is available, and requests a block from the server, if th6 
• •:• block is riot yet available, the system riaay alsb include a player which arranges for 
the execution of the structured information. 

Additionally, the invention may provide methods for providing multiple 
levels of support for executing over a <x>mpto 

30 executable code, comprising providing, for a plurality of network performance levels, 

-4- 
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aplurality of load maps associated with respective ones of said network performance 
levels and having a list of sections of executable code of the program ordered 
according to the expected priority of access of the executable code by the program, 
determining a network performance level available through the network to a cHent, 
selecting a load map as a function of the network performance level available, and 
allowing the client to request sections of the program according to the load 
map selected. Optionally, the method may mclude pmcessmg foe program to 
generate foepluratity of load maps. To foisend processing foe program includes 
deternuning for a respective network performance level a preload list representative 
of a series of sections of executable code that are to be transmitted over foe network 
prior to execution of foe program 

Processing foe program includes monitoring execution of the program to 
determine a sequence of block fetches for moving sections of executable code into 
cdmputermemoryand^ Generating an ordered list 

includes ordering foe list to provide a delivery sequence for scheduling delivery of 
sections ofexecutable code over the network to foe client. Generating foe ordered 
list to schedule transmission ofexecutable code over foe network during a period of 
low network activity during program execution. 

The method may determine a network performance level by launching a 
player program at foe client capable of exchm&gMomx&onvdlkiiT^ote server 
fordetermimngfoeavailablenetworkbaridwidfo, mcludmg launching a player 
program at foe client capable of exchanging information with a remote server for' 
detennining network latency. 

Optionally, determining a network performance level includes deterniining 
25 cacheinem^ 

network performance level to a threshold level and preceding to selecting of a load 
map as a function of foe comparison. 
Ofoermefo 

of support for executing over a computer network a program having blocks of 
executable code, comprising providing a file system management process for 

-5- 
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monitoring file access operations of a computer progi^ executing within an 
: application memory space, executing the program, employing the file system 
management process, while the program is being executed, for determining a 
sequence and a timing pattern with which blocks of executable code are loaded into 
5 the application memory space, and processing the sequence and timing pattern to 
generate a load map representative of a sequence and timing pattern for transmitting 
blocks of executable code over the network. 

As discussed above, generating a load map includes processing the sequence 
and timing pattern to identify periods during program execution available for 
10 transmitting additional blocks of executable code. This may include determining 
probabilistically the additional blocks of executable code to deliver over the network, 
as well as processing the sequence and timing pattern while collecting information 
representative of blocks of executable code requested from a remote site and adjusting 
the load map as a function of the collected information. Optionally, the method may 
1 5 add trigger controls within the generated load map for controlling post-load execution 
on a client based on programs file accesses. 

Other objects of the invention will, in part, be obvious, and, in part, be shown 
from the following description of the systems and methods shown herein. 
Brief Description of Drawings 
20 Figure ! depicts schematically the structure of one embodiment of a system 

according to the invention; 

. figure 2 depicts on example of a Load Map; and 
Figure 3 depicts graphically the download demand for a title versus time. 
Best Mode for Carrying Out the Invention 
25 To provide an overall understanding of the mvention, certain iUustrative . 

embodiments will now be described However, it will be understood by one of 
ordinary skill in the art that the systems and methods described herein may be adapted 
and modified for other suitable applications arid that such other additions and 
modifications will not depart from the scope hereof. 

-6- 
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The systems and methods described herein include systems for delivering 
content over a data network, and more particularly include systems and methods for 
delivering executable content over a data network, in a manner that allows a user at a 
remote site to access the content on demand to have a user experience that is 
comparable to the user experience that would be achieved if the content were being 
accessed locally 

Among the features of the invention is the ability to allow a holder of an 
executable title to securely deploy that title for use by users at remote client systems, 
and to provide that user with an acceptable user experience. To tins end, and as will 
be explained in greater detail herein after, the systems and methods described herein 
include systems and methods that analyze the throughput available for delivering data 
betweenthecUentandthe server. Based on this determined throughput, the systems 
select a delivery schedule and method for transferring data tothe client Moreover, 
the systems monitor the client's use of the content to determine what other content' 
15. shouldbep re loadedor<^hedonmec^ 

content is comparable to the access the user would have if the content was stored 
locally. Examples of such systems delude cheht/serv^ 
remote client system to access an executable title stored at a remote location and to 
run that title locally on the client system by retrieving on demand portions of the 
executable content from the remote server. The systems and methods may further 
include a mechanism for detennining the network characteristics and throughput 
avauable for transmit Upon determining 

memea^ofavailab^ 
memo<ls described 
25 and throughput to ifclectato^ 

identified characteristics and available throughput The load map file may, in one 
embodiment, be a data file associated with the content, or title, that the user at the 
remote client desires to access from the server and execute locally at the client To 
this end, the loadmap file may be a data file associated with and representative of a 
30 tiflethatlmbeenfo^^ 
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title more easy to segment and to deliver in sections across the data network and to the 
remote, client 

Additionally, the load map may include predictive loading informatiori. The 
predictive loading infonnition may be inforaktioh that can be employed by a load 
5 map reader to fetch segments of the title from the server. To this end, the load map 
may include a method and an ordered list of data blocks to be fetched, without * 
considering the progress of the particular title session. After the title is launched, the 
client is to fetch blocks on this ordered list per the defined method in the given order 
when- the network conditions permit Optionally, the load map may also include 
10 information in a tree structure that is representative of a list of a set of blocks, each set 
being associated with an additional set of blocks. If the client detects that the blocks 
in the first order set are being fetched by the title, then the blocks in the second order 
set are to be loaded. This provides for probabilistic loading. In either case, the load 
map data file may include information and methods that allows a client to download 
15 blocks of executable code from the server to the client This probabilistic loading, in 
combination^ with the use of load maps, can provide the User with a user experience 
that is comparable to the user experience the user would have if the content were 
stored locally. 

For purposes of illustration, the systems and methods of the invention will be 
20 described, in part, with reference to certain illustrated embodiments. These 

embodiments will largely encompass examples of systems and methods suitable for 
allowing a user at a remote client to access and execute a computer program, such as a 
video ganie. br other ^plication, maintained sat a ieniote server. A computer game 
miay comprise both executable code as well as data including images, text and other 
25 types of data content However, it will be apparent to those of ordinary skill in the art 
thatthe^ 

applications described below aid that the systems aaid methods of the invention may 
\ encompiass other applications and features includihjg applications for delivering media 
content over a network, web browsing, vife conferencing and any other application 
30 where it will be beneficial to coordinate the available network resources with the 
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expected demands on the network when exchanging data from one site on the network 
to another site. 

One embodiment of a system according to the invention is depicted in Figure 
1. Specifically, Figure 1 depicts a system 10 that employs a client/server architecture 
5 to allow a user on a remote client to execute locally a title that is maintained at a 
remote server. Specifically, Figure 1 depicts a system 10 that includes a server 12, 
that optionally may comprise multiple servers 62, 64, 68,1 8 and 20. and a client 14 
The structure of the client 12 and the server 14 mcludes elements described in detail 
in the above identified US patent appticatior* andPCT applications: 60/231,992- 
10 entitledSystermandMemodsforDefivermg^ntentOve^ 

filed 1 1 September 2000 and naming Joe D. Croman as an inventor; 60/108 602- 
09/3 1.0,294; 09/31 1,923; 09/310,229; 09/439,906; and PCT/US99/271 13, whicbare 
commonly assigned, co-pending applications. For purpose of clarity, foese following 
description describes the structure and operation of the server 12 and the client 14, 
15 including the operation and structure of certain elements of the server 14 and client 12 
which were also described wim teference to the systems aud methods shown in the 
co-pending applications identified above. However, for purpose of clarity, and to- 
avoid redundancy, the above identified applications have been incorporated by 
reference to provide former understanding ofto 
20 alternative embodiments, practices and uses.of these certain elements. 
The DlustratftH ,Wr 

The depicted server 12 foriudes a server front end 16, a dispatcher 18, a RAFT 

v of title load maps 24 a, b and c respectively, and an optional profiler 28 and an 
25 optional running title 30. 

The server front end 1 6 includes a web storefront 62, an e-commerce server 64 1 
and a conditional access server 68. The server frbnt end 16 aUows a user to negotiate 
a transaction with the server 12 to purchase ^ 

Theserverfrontend 16ismcommuni te tion^ 

18 illustrated in Figure 1 discovers local RAFT servers, tracks their relative loading 
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and bandwidth delivery, and provides this information upon request optionally to the 
conditional access server 16 and optionally the Player 38 of the client 14. There will 
typically be only one instance of the Dispatcher service running per bank of RAFT 
servers, although the design should allow for fail-over as well. 
5 The Random Access File Transfer (RAFT) server 20 may be a read-only 

content server designed specifically for Internet-based content distribution. The 
RAFT server 20 may also be designed to enable proxy or cache servers oil the 
network. The RAFT can enable dynamic bandwidth restrictions and employ other 
methods to prevent network congestion. More specifically, the RAFT server 20 is 

10 capable of serving content to the client 14 . In particular, the client 14, after having 
negotiated with the store front 16 to purchase access to a title, contacts the RAFT 
server 20 to gain access to that title. The RAFT server 20 can verify that the client 14 
has purchased access to a particular title 22, and can provide the .client 14 with access 
to that title. To this end, the RAFT server 20 can process a request from the client 14 

1 5 that includes a protocol version, the path name for the title and an access token. The 
jprotocol version is a 32-bit value used to verify that the client and server are protocol 
•compatible. To validate access, the RAFT server 20 verifies the token is valid In 
those applications where the user purchased a limited amount of access to the title, the 
RAFT server 20 can monitor the parameters of the users access requests to make sure 

20 they stay within prescribed limits. For example, the user may have purchased a 

limited amount of access time, or access to only certain portions of the title, or some 
other type of limited access. The RAFT server can check the token's parameters, 
such as its start and expiration times during the opdn. If the RAFT OPEN is 
successful, the RAFT server returns a RAFT file handle and a unique ID for the briq 

25 associated with the title, typically, the ItAFT acc^s tokra will eventually expire, and 
the RAFT server 20 will no longer grant access to the title 22. 

The RAFT server 20 may be implemented as an application executable oh a 
POSDC1 (IEEE Std 1003.1, 1998) compatible platform, such as the Sun Solaris® 
operating system commercially available from Suh Microsystems, Palo Alto, CA, or 

30 the Linux operating system commercially available from Red Hat Software. The 
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RAFrservermybeimplementedasal^a^^ 

Management Protocol (SNMP) master agent executing on top of the operating system. 
A commercial product suitable for implementing the SNMP master agent is the 
Emanate product commercially available from SNMP Research, Inc. The master 
5 agent communicates with the network using published application program interfaces 
m accordance with the SNMP standards. 

The server 12 furfo^^ 1 ^ 

embodiment of Fig.1, atitle 22 is formatted into an electronic package that contains 
the title's files in a compressed and encrypted form, referred to as a briq. Thus, title 
1 0 software used in the system of Figure 1 is packaged in briqs 22. The briq 22 contains 
the executables, support software, and data files, arranged in the appropriate directory 
structure. Additionally, the briq may contain metadata that that supports an install 
abstraction, security, system requirments, and om^ 

the title to execute locally. At the layer connecting the client 14 with the server 12 
15 data is fetched in discrete units, referred to as Blocks. For ease of management, the 
block size may be fixed at some power of 2, such as 32768 bytes. When the title " 
nnming on the client 14 makes requests for directory, executable or content 
information, which are to be satisfied from me associated briq 22, mese requests are 
translated to some extent of bytes in the associated briq 22. The client 14 then fetches 
20 foeBlockorBIocksmwM^ 

self-contained file system, <»ntaiimig mes and meta-data to be employed ' 
particularthle. Briqs 22 restored on the ffle server 12, or a storage device or system 
accessible bymeserverl2ortowhichmeserverl2c^ 14 . 
• Figurelshowsthatmeserverl2mcludesaplurafi^^ 
25 emboo^entofFigurcl, each ofme depicted 

separatetitleortitles. For each title briq 22 there are a plurality of title load maps 24. 
^ different load maps 24 for each respective title briq 22, provide different loading 
profiles or loading schedules and methods for the respective title briq22, wherein the 
difference in loading profiles or load scheme and memcxls arises from the diff^ 
30 m network characteristics and throughput that can arise when users request access to a 
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particular title. Thus, for example, during the course of a day, two separate users may 
negotiate access to the same title. To provide a quality user experience, the system 1 0 
may determine the network characteristics and throughput available to server for 
delivering the blocks to the user. In this example, the first user may have a high speed 
5 cable access that is providing about 1Mbit throughput and minimal latency. In 

contrast the second user may have a DSL connection that is presently burdened and is 
providing about 300 Kbit throughput with high latency. Thus the ability to provide 
the user with timely access to the data needed to run the title on the user's local 
machine differs between the two users. Thus, in the case of the first user, the server 

10 has 1Mbit of throughput available and low latency. Throughput may be understood as 
the rate at which data may be transferred between the Raft server 20 and the player 
38. The throughput is effected by the network resources, including bandwidth, 
latency, QoS and other factors. Thus, the server 12 can employ a schedule and method 
of access that downloads the blocks necessary to begin the title run, and can service 

15 the title's request for more blocks on demand on a network channel that provides 
1Mbit of throughput In contrast, the server 12 has only 300Kbit of throughput to 
service the second user. Thus, the client may need to preload a greater number of 
blocks into cache prior to the title starting in order to preserve the quality of play. In 
addition a second access method may be deployed by the client under these network 

20 conditions to request further blocks from the server, not on demand, after the title is 
ninningonthecfe^ The 
point - is that with high throughput between the server and the client less data needs to 
be preloaded into cache before the title is launched and more of it can be delivered 
real time as the title plays. ; 

25 To address the possible disparity aid changing network conditions of 

throughput available between the server 12 and different users, the system 10 of 
Figure 1 provides a plurality of load maps 24, whore the load maps 24 provide a 
. delivery schedule and access rnethods thai is adapted to support delivery of title 
content for the associated network charactcaiistics and throughput in a manner that 
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achieves a user experience for the running title that is similar or identical to the user 
experience the user would have if the title were lunnmg locally. 

Tothisend, theload maps 24 rental 
52 on the client 14 can use to request blocks from the server 1 2 with a schedule and 
method that shomd make btoksa^^ 

needs them, thus providing a user experience that is identical or similar to the user 
experience the user would have if the title were stored locally. To this end, load ' 
maps, like load map 24, work in conjunction with the local cache. If arequest is 
made for data and it is not in the cache it goes directly to RAFT server. Thus, as the 
timeliness by which blocks may be transferred across me xbta network turn 
available network throughput and characteristics, a separate load map 24 may be 
generated for each network environment employed by users. Thus, if experience' 
shows mat users employ network connections providing one of three throughputs and 
characteristics, 3Mbit or greater with QOS, 1Mbit wim high latency or 300Kbit with 
low latency, each tide can have thr^ 

and method of access suited for a respective one of the three bandwidlhs. 

More specifically, the load maps 24 may describe the content access patterns 
of the titles 22, parameterized typically by time, by access history and by runtime 
state of tide. Additionally load maps may contain the access methods to be deployed 
by for a given access pattern and runtime title state. The load maps 24 cooperate with 
associated load map readers 52, to provide vehicles for distributing information about 
title behavior and state, in terms of accessing blocks within the briq, to the client- 14. 
The load maps 24 contain data and the load map readers 52 contain executable code 
to interpret me information of the load maps. Tie load map readers 52, monitoring the 
runmng titles brig network utfetion, and op 

perform the client cache transactions for sustaining the title experience when client ' 
ban(lwidm islinuted TypicaUy, me 

developed by observing and analyzing the behavior of a class of titles and developing 
algorithm and access methods that best support the class of behaviors. For individual 
tifles data that defines title behavior is then collected from a number of title runs by 
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the profiler 28, and aggregated and encoded into load maps 24 for the title that 
corresponds to the map reader and network conditions Additionally data that defines 
title behavior can also be collected from the cache manager 40 as titles are run my 
remote users. 

Load maps in the embodiment 6f Figure 1 are stored in load map containers. 
One such load map container 80 is depicted in Figure 2. Each load map container 80 
is associated with one briq. A load map container 80 contains one or more load maps 
82. Each title in the briq 22 is associated with a set of load maps 82 within the 
container 80. Each load map 82 in the sk is associated with a Network Metric 
Descriptor 84. : 

In one practice, when choosing a load map 82 for a title session, the client 14 
locates the load map container 80 for the title's briq 22, locates a title load map 
directory within the load map container 80, and selects the load map 82 within this 
directory which is associated with the Network Metric Descriptor 84 closest to the 
network environment in which the title session is to take place. Typic^y, the client 
14 compares the available network throug^ut anH characteristics with information 
within the Network Metric Descriptor 84, aiid roakes the selection based on this 
comparison. 

Each load map 82 may contain some or all of the following information stored 
in different fields within the container 80: cache placement information 88; preload 
information 90; and predictive loading information 92. Cache replacement 
information 88 can comprise information which is used by the client 14 when storing 
incoming data in the client's cache. Bus infonnation can include, for example, the 
cache replacement algorithm to use, e.g., Least Recently Used (LRU), priority cache 
list or some other suitable algorithm for ^^ deteiMMng vdiat infonnation to keep in the 
cache. The infbimation can also include th^ amount bf cache space to be allocated 
exclusively for the title; and the relative caching ipriority of each briq block, used by 
the cache replacement algorithm when thfe subject block is considered for insertion 
into the cache. 
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The preload information may contain a list of briq blocks, which are to be 
present in the client's cache before the title's executable is launched. Typically, the 
faster the network throughput, the smaller the number of blocks that need to be ' 
preloaded into cache prior to me tide starting execution. In either case, those blocks 
that need to be preloaded may be stored in the field 90 as an ordered list 

The load map 82 may optionally contain predictive loading information in 
field 92. This information may be used by the load map reader 52 to fetch briq 
content while the tide is running, even though the tide 48 has not yet accessed them. 
This information may include one or more of me following: 

An ordered list of briq blocks to be fetched, without considering the progress 
of a particular title session. The client 14 is to fetch blocks on this list, in the given 
order, during periods when the running tide's network activity permits,. This list is 
known as a postioad list. 

Alternatively, the field 92 may contain a tree structure of sets of briq blocks 
15 each set potentially associated with multitude of branching secondary sets. If the 
clientdetectethatmeb^ 

blocks in the second set are to be loaded based on the probability access. This list is 
known as the Probabilistic loading list, and this is the type of list depicted in Figure 
2. The date structures associated wiffi 

structure of sets of date. Each of these sets contains the Mowing elements: Event 
definition: A set of triggering events that would cause the cache manager 40 to signal 
memapreadertocontinuewimiteprobabflisti^ The cache manager 40 

may pass to the map reader 52 event information such that the map reader 52 could : 

along with its current state determine whiftb.*.r<»* «>♦ i : A. it . 

wicniune wnicntarget set of blocks from the tree would 

25 be loaded next. 

Target set: An ordered list of blocks in the briq, which are likely to be required 
by the title in the near future. 

Probability of correctness: The probability that, if the event is detected, the 
target setofblocks would be required by me runn^ ' 
30 considermgapluraUtyofeventsahdchbosm^ 
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Longevity of prediction: The span of title activity (quantified in title briq 
accesses anil/or in wall clock time), which the prediction claims to cover. After this 
span is exhausted (the title has performed this many briq accesses, or that much time 
has passed, since the putative event), the prediction is pronounced stale and would be 
ignored. 

Thus, the load map 24 contains information that the lad map reader may 
employ for downloading blocks from the briq in at manner that maintains the desired 
user experience, 

; • Turning now to Figure i, one example of how a load map 24 may be 
employed for delivering content more efficiently over a network is depicted 
Specifically, Figure 3 depicts the load demand for a title over a period of time T. . 
Also depicted in Figure 3 is the available bandwidth. The available bandwidth is 
rioted by the horizontal line BW, and for the depicted example the bandwidth is 7681L 
As can be seen during the time period T, the load demand for the title sometimes rises 
above the available bandwidth. These peak times are shown to as having dashed lines 
exteridiiig through the peaks (F, 2\ 3'). Sirnilarly, there are; also times when the 
bandwidth available exceeds the bandwidth.reiquired by the running title. For 
ihstancfe, this may occur because the running title has loaded all the blocks it needs to 
support a task that typically requires the user to spend a meaningful amount of time 
performing the task. To address this issue the load map 24 may be employed to 
schedule delivery of blocks of the title during those times of excess bandwidth, and to 
employ those times to deliver data into a cache on the client This is shown in Figure 
3 by the reversed peaks (1 ,23) that present the delivery of blocks that are predicted 
to be needed in the future. This preload^ ^ accessed 
by the executing title, without requiring the system to eiriploy the network. 

The activity of the map reader to request data to be delivered over the network 
during times of excess capacity turns in part on the map reader's analysis of the load 
map. In particular, the load mkp may include a decision tree and access methods that 
sets out an outline for possible file access patterns for the title given certain operating 
conditions. The decision tree may be employed by the map reader to generate data 
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requeststotheRAFTserver. By predictively caching portions of the executable the 
system provides better real-time performance for the title. 

The Profiler 28 component is the primary piece of the title preparation 
process. It observes me execution ofa title 30 and creates one or more load maps 24 
> ^onanalysisofmetitie'sdiskacc^spatterns^ 

characteristics. The process employed by the profiler 28 can depend upon the 
application. Typically, the profiler 28 monitors the access patterns of a title as a user 
employsthetitle. Additionally the profiler can receive and use title access patterns 
from remote users that accessing a deployed system. The profiler 28 can build a log 
of these access. Given some useful patterns, possible profiling and map reading 
algorithms can be tested and validated by simulation. Then the appropriate 
components can be developed to support each map type. 

Note that the architecture of Figure 1 depicts load maps 24 as distinct from 
the title briqs 22 for reasons of both clarity and efficiency: load maps will be . 
comparatively small and are likely to be ^upd^ much more often than the title 
content Load maps will need a version link to keir correspond^ 
server 20 data synchronization is not a problem. Logistical (distribution) issues could 
fore* load maps to become physically part of a brio, but such as change is within me 
skill of the ordinary artisan.. 

The load map format and map reader algorithms may vary according to 
application, and based onfactors such as time, action withm tide, disk access and 
.quality of runtime experience (freezes), and statistical analysis may be employed to 
find patterns; 

The two components which have direct knowledge of tide deh^ 
aretire RAPT server 20 and the cache manager 40 of the cheat 14. Each should track 
bandwidth and be queryable by the Dispatcher or Player/store front so that the 
customer can be presented with appropriate choices and estimates of delivery time 
In addition to the Dispatcher 1 8 , it may also be desirable to have a daemon 
process thatresides on the Client 14 wmch periodically mea^ 
availability when the cache Manager 40 is idle. This would allow the Dispatcher to 
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stay up-to-date with network conditions and be queryable directly by the server front 
end 16. 
The Client 

As shown in Fig. 1, the depicted chent 14 includes a web browser 32 having 
5 plug in 34 , a player 38, a cache manager 40, a plurality of title caches 42 a, b and c 
respectively, and a cache admin tool. As further shown the client 14 includes a 
running title 48, a plurality of map readers 52 a, b and c respectively and a plurality 
of cached title load maps 54 a, b and c respectively. Although only one server 12 and 
one client 14 are depicted in Figure 1, it will be understood that the systems and 
10 methods described herein include systems and methods where multiple servers 12 are 
employed and where each server may support a plurality of client 14. For example, 
depending upon the application, the server 12 may support a thousand client systems 
14. 

The web browser may be any suitable web browsers, and typically comprises 
15 an HTML browser such as NetScape Navigator or Microsoft Explorer. For the 

depicted embodiment, the browser is provided a plug^in The Plug in allows the server 
front end 1 6 to communicate with the player: and to cause actions on the player side 
and to gather data such as version numbers, throughput measurements, and other 
information However, the type of browser employed will depend upon the 
20 application, and in those applications where the device is unable to support a typical 
browser, a proprietary client application may be provided for exchanging data with 
the server 12. sr- 

The player 38 depicted in Figure 1 may be implemented as a Windows 
application containing logic which coordinates torto between the client 14 

25 and the CAS 68. The player 38 may be invoked by the client's browser 32, and may 
include a library which may be implemented as a series of objects or program code 
which generate and receive communications to/from the CAS server 68 through 4 
remote procedure call (RPC) library. The player 3 8 may also include a process for 
moving data across the network and for measuring available network resources arid 
30 characteristics including throughput, bandwidth, latency, buffer capacity and other 
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parameters. Additionally, the flayer is capable of processing information provided by 
the server 12 to determine for a title of interest to the user, which of the plurality of 
available load maps for that title should be employed. 

Upon invocation of player 3 8, a graphic user mteriace (GUI) is presented to a 
5 ^.hmemustrativeenu™^^ 

program logic and/or objects necessary to interface with the operating system and 
application programCAPIs) contained within the Windows or other operating systems 
or environments in order to render Windows, present graphic information within such 
windows, and receive commands from auser viaa keyboard, mouse or other input 
10 devices, such user interface being well Within the scope of those reasonably skilled in 
the art' Through this GUI, the user may set user preferences, e.g., disk cache size, and 
be notified of error conditions. The player 38 can launch a title and continue 
communications between the client 14 and the CAS 68 and the RAFT server 20. 

The depicted Player 38 is also an intermediary between the CAS and the cache 
15 manager, hi the process of running a title, the player 38 locates the BSP's Dispatcher 
service 18 and queries it for information about a suitable RAFT server; tells the cache 
manager 40 which RAFT connection to make; provides the RAFT title or content 
access keys from the CAS to the cache manager 40, and refreshes them with the CAS 
68asneedeo. cormgures me appropriate map reader 52a,b,c^ 
20 inforniation,suchasbandwidmanddekymodei^^ 
application as needed. 

The player's 38 interaction with the Dispatcher 18 may optionally include a 
; bauowd* 

cache space if fo^ 

25 

Each cache may be associated with a specific body of content. The cache manager 40 
responds to requests from the player 3 8, which cormgures it to connect with a specific 
RAFT server 20, briq 22, and load map 24. The cache manager 40 may also respond 
to the map reader 52a,b,c, which makes anticipatory load requests that are driven by 
30 ?? tifle ' S load ma P 54a > b ' c md cur rent execution state. 
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The cache manager 40 provides a block directly from the local disk when it is 
available, and makes a request of the RAFT server 20 for blocks it does not have a 
local copy of yet The algorithm by which the cache is managed can be simple LRU 
optionally, may also encode and use load map information that preserves critical 
5 cache data which may not be accessed frequently by the title. The profiling process 
will determine substantially optimum cache size for each title, and possibly for each 
bandwidth tier in which title may execute. 

The cache manager 40 also records the load state of the cache, which means 
that it knows which blocks are in cache. This information allows the map reader 
10 request that are not in cache to access the content server 20 and allows the player 38 
to determine whether the title should be allowed to run or not 

The cache admin tool 44 provides a GUI which allows administration of local 
caches by the end user. It shows how much disk space is taken up by each title and 
allows 1he user to dispose of cache blocks for titles that are no longer needed. The 
15 user can start this tool manually or it may be run by the player 38 when 
reco^guratioii of ciche space is necfcssaiy; 

As discussed above, the depicted map reader 52a,b,c interprets a profiler- 
generated, title-specific load map 54a,b,c that has been downloaded from the server 
12 to the client 14. As shown in Figure 1, for a given network state a separate load 
20 map 54a,biC is present for each title 48. The load map 54a,b,c describes the content 
access patterns of the title application, parameterized by time and by access history. 
As discussed with reference to Figure 3, the map reader 52a,b,c uses a load map 
54a,b,c to create cache pre-load requests Which are meant to anticipate the disk ' 

25 available as soon as possible and avoids title fitezeS during execution. To do this, the 
map readeir 52a,b,c uses the pfbfiler load map daitat to "lead 5 * the title accesses by a 
time delta which will be variable during execiition. 

The Map Reader API and one or more illustrative load map formats and map 
readers may become a part of a title developer SDK as well. 
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Accordingly, Figure 1 depicts a block diagram that shows the different 
elements of one embodiment of the invention, which embodiment comprises a system 
fordehvermgconten^^ 

remote location* In the system 10 of Figure 1 the server 12 and the client 14 
5 cooperate to deliver portions of executable code over the data network in a manner 
that allows a user operating the client PC, or some other remote device, to execute the 
program on the remote device in a manner that provides for the same, or substantially 
same, .user experience that the user would have if the executable code was part of a 
program that was stored locally and accessed by me cHeht dev^ 
10 applying the client server architecture of Figure 1, the system 10 is capable of 

providing a server system that any client ^access for me purpose of downloading a 
progrm^rtitie.thatfoeuserismterestedmru^ For this particular 
embodiment, the server 12 includes a front-end 60 that comprises a web storefront 62 
an e^ommerce server 64 and a conditional access server 68. Ine front-end 60 
15 therefore provides an electronic storefront that may broker a transaction for allowing a 
user to purchase access to a title stored on, or otherwise accessible to, the server 12. 
Operation of the Depicted System i n 

In the depicted embodiment, ttseramay ^atitietormfromavirtaal 
storefront provided by the storefront system 1 6, which contains a virtual catalog of 
20 availabletitles. Upon selection ofthetitle, the user negotiates for ah actual pur^ 
of m etiue.Negotiationn^ 
commerce system, pro^ 

purchase types offered with the selected title. Examples of possible purchase types 
may include a time-limited demo of the title, a smgle payment for a single use" of a 
25 titie,asmglepaymentwMcha^ 
time period e.g., week, month, etc. 

For the depicted embodiment, the server 12 includes the front-end 60 that 

pmvides me above-described electmnic storefront However, it will be apparent to 
foosc-ofordinaryskmrnme^ 

of front-end navigational server depends on the application at hand and an alternative 
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embodiment, the navigational server may be removed from the systems and methods 
described herein. Additionally, the particular embodiment of Figure 1 shows the 
front-end server 60 as including a transactional e^cbmmerce server 64. It will be . 
understood that the transactional e-commerce server 64 may comprise a server system 
5 integrated into the Server 12, or, in alternate embodiments, may be supported by a 
third-party service provider such that the e-commerce server 64 may be located at a 
remote location and not integrated into the front-end 60. Other elements shown in the 
front-end 60 including the web storefront, may also, in whole or in part, be supplied 
or supported by third-party systems that are accessed, but remote from, the front-end 
10 60. 

However, continuing with the example system of Figure 1, the user would 
negotiate a transaction to receive access to the title of interest. Upon completion of 
the purchase negotiation, then client software running on the user's PC obtains an 
. authorization token and keying material from the Conditional Access Server (CAS) 

15 68. The token authorizes the client 14 to run the selected title from the file server 12 
across the network, the data retrieved from the file server 12 is encrypted. The client 
14 uses the keying material provided by the CAS 68 to decrypt the data from the file 
server 12. In one specific example, the eCommerce server 64 generates a launch 
string, containing the information identifying and authorizing the purchase, including 

20 a Universal Resource Name (URN) uniquely identifying the desired title. The launch 
string may be digitally signed by the CAS 68 and provided to the eCommerce server 
64 for delivery to the client 14. 

The launch string, in one practice is wrapped with a MIME header. When the 
launch string is received by the client's browser 32, the MIME type associated with 

25 the launch string is located in a registry entry, which results in the invocation of & 

player module 38 within the client 14. The player module 38 establishes a secure RPC 
connection with the CAS 68 and requests that CAS provide a URL for the specified 
URN , i.e. a URN to URL conversion. The URL identifies the location of the 
corresponding title data. The CAS 68 forwards the corresponding URL to the player 

30 38. Once the player 38 has identified the location of the corresponding data, the player 
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38 sends a purchase request to the CAS 68, the purchase request including the Launch 
string. 

With this embodiment, titles run on the user' s PC, but the title is not 
downloaded, in its entirely, onto the PC. A title is formatted into an electronic 
package that contains the title's files in a compressed and encrypted form, referred to 
as a briq. The briq is aportable, self-contained file system, containing Ihe data that 
makes up the files to be employed to run a particular title. Briqs are stored on the file 
server 12, or a storage device or system accessible by the server 12 or to which the 
server 12 can refer the chent 14. Ihe server that manages the titles is referred to 
hereafter as the RAFT server 20. The client 14 treats the briq like a local file system 
on the user's computer. When running a title, the operating system, e.g. Windows 
makes read requests to this local file system. The client 14, which, in the iUustrative 
embodiment, includes a cache manager 40, services these requests by retrieving the 
requested blocks Of briq data from the RAFT server 20. After retrieving the requested 
block of data, cache manager 40 decompresses and decrypts the briq data, and passes 
the data onto the operating system on the user's computer. 

Tuning, to Figure 1, one example of such an operation canbe described. ' 
Specifically, for the system 10 of Figure 1 the CAS 68 verifies the launch string's 
signature,^ 

The authorization token may be actually embedded within the activator. Next, the 
player 38 launches the title by passing the activator to the cache manager 40. 
Thecachenian a ger40runstheactiva to r and opens the URL and reads the header 
The cachemanager 40 sends the imtial aumbrization token to the RAFT Server 20 
The cache manager 40 starts reading content from RAFT server 20. The cache 
manager 40 uses the activator to decrypt and decompress the content in the form of ' 
bnq data, and perform integrity checking on the blocks of decrypted data. 

Thereafter, the operating system executes the title, via the local file system 

the CAS 68 to refresh the activator and the RAFT authorization token. Upon the first 
10 of suchrequests, the CAS 68 posts the purchase to the eCommerce server 64 for 
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transaction settlement The lifetime of the first activator may be on the order of 
minutes. Successful activator refresh after the first timeout serves as an indication that 
the title is running successfully on the client 14. 

Thus, in this embodiment the software title is never "installed" on the client 
5 14. The client 14 creates an installation abstraction, maintaining the illusion for the 
operating system that the title currently executing is installed on the host computer. 
Thus, when execution of the title is terminated, there is no remaining evidence the 
title ran on the system. No files associated with the title are left on the computer's 
hard-drive, and no operating system state irifonhation e.g ; , registry variables 

10 associated with the title, remains. Optionally, users of titles have the option of saving 
certain. state information that would be desirable to rnaintgin across plays; e.g., the 
"level" achieved in a game, etc. Such state information may be saved in write through 
file described hereinafter. 

Optionally, the client 14 uses the Random Access File Transport (RAFT) 

15 protocol to retrieve briq data across the network. The protocol, in one practice, may 
provide the client 14 with read-only access to files and directories stored on RAFT 
server 20. Because the briq is treated like a local file system, the RAFT client does not 
need to be visible as an operating system drive and does not need to interface with the 
operating system's file system manager, the Windows Installable File System (IFS) 

20 Manager in the illustrative embodiment As a result, the RAFT client file system - 
driver, the cache manager 40 in the illustrative embodiment, is smaller and simpler 
than a remote or network file system driver. Optionally, the RAFT protocol supports 
dynamic bandwidth restrictions ,e.g., ^andtwdth thwttiirig^% and access control 
through the use of RAFT authorization tokens; 

25 The client 14 may employ a variety of 

from unauthorized access and replay. Authorization tokens and dec^tion keys are 
obtained from a CAS 68. Network communication between the client 14 and CAS 68 
may be protected via a secure remote procedure call (RPC) interface. Once a secure 
channel is established between client 14 and CAS 68, the client 14 requests a RAFT 

30 authorization token and keying material for the s^lectecl title. The authorization token, 
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in one embodiment may be a signed message from the GAS 68 indicating tbat the 
requesting user can have access to a specified briq, Oh a specific RAFT file server 20, 
for the length of time spelled out in the negotiated payment type. 
While the RAFT authorization token gives a client 14 access to a title's briq, the client 
5 14 in certain embodiments, is to unpack, e.g. decompress and decrypt, the briq to gain 
access to the title's file data. The CAS 68 provides the user with the keying material 
to decrypt briq data. In one practice, the CAS 68 does not directly provide the client 
Mwifckeymg^ 

by embedding the keys in obfuscated bytecode that implements the decryption 
1 0 algorithm. Rather than delivering isolated keying material to the client 14, the CAS 68 
delivers obfuscated bytecode, referred to as an activator. The client's cache manager 
40 decrypts briq data by naming the activator on a bytecode interpreter. Optionally, 
both the RAFT authentication tokens and activators may have a limited lifetime. For 
example, in certain embodiments, ^^ authorization tokens include an expiration time, 
1 5 after which they are no longer valid. Similarly, a running activator, at a certain point, 
may initiate an exchange with the CAS 68 to refresh itself. If the exchange is 
unsuccessful, the activator becomes inoperable and the title inoperable. The refreshing 
of activators is referred to as activator keep aliVe. 

ItwmbeunderstocjdthatmesystemdepictedmFigure 1 maybe supported by 
20 or implemented on (^nventionda^pKM^mg equipment For example, the client 
systems can be any suitable computer system such as a PC workstation, a handheld 

.... ^ 

equippedwithanetworkctientcapable 
. with the server to exchange information with the server. In one embodiment, the 
25 network client isawebchent, such asaweb browser mat c^ 

web browser, the Microsoft Internet explorer web browser, the Lynx web browser, or 
aproprietary web browser, orwebctiem 

web server, and ftp server, a gopher server, or some other type of network server. 
The servers may be supported by a commercially available server platform 
30 such as a Sun Sparc™ system and running a server capable of connecting with, or 
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exchanging data with, one of the subscriber systems. In the embodiment of Figure 1, 
the server includes a program for delivering content over a TCP/IP data network. 
Such programs may be written using principles known in the art. 

It will be noted that Figure 1 depicts the elements of the systems as 
5 functional block elements. However, it will be apparent to one of ordinary skill in 
the art that thesb elements can be realized as computer programs or portions of 
computer programs that are capable of ruiming on the data processor platform to 
thereby configure the data processor as a system according to the invention. The 
elements, such as the player and profiler can be realized as a software component 

10 operating on a conventional data processing system such as a Unix or Windows 
workstation. In that embodiment, these mechanisms can be implemented as a C 
language computer program, or a computer program written in any high level 
language including C++, Fortran; Java or basic. General techniques for high level 
projgramming are known, and set forth in, for example, Stephen G. Kochan 

15 Prdgrtim^ginC^ 
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Claims: .• 

1. • A method of transmitting data over a network, to support execution of a 
program at a remote location comprising 

detenmning a measure of available throughput for transmitting data over the network, 
identifying information to be transmitted over me ne^ 
looking load map of information for a given execution state of the program, and 
based on the load map and the execution state, generating an anticipatory load request 
for transmitting the information withm the available throughput and for maiiitaiiiing 
consistent execution of the program. 

2. The method of claim 1, wherem me information comprises at least one of data 
or an executable file. 

3. . The method of claim 1, wherein the information is transmitted ftom a server to 
a client 

4. The method of claim 1, wherem identifying information includes selecting 
information based on the available throughput and the execution state of the program 
at a tinie of selection. 

5. The method of claim 3, further Mx^ri^g: 

the client requesting information to be transmitted, 

I a subset of the Monnatioh based on the available 
at a time of selection, iand 
the client selecting, for tran^o^ cUent, information 

from the subset of the Morniation. 

6. Tleinethdd ^ ; ; 

the client requesting information to be trananitted, and if the request is approved, 
receiving akeyada^ 
the client 

7. ^emettiodofdaxml,v^^ 

based an access pattern for the transmitted infoiMtioa 

8. A system for transmitting stractured iitfoimatioh over a network having an 
identified available throughput, compnsmg: * 
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a server providing the infonriatioh, 
a client receiving the information from the server, 
a profiler monitoring transmission of the information from the server and 
generating at least one load map based on an analysis of an information access pattern 
5 atthe server, 

a map reader, based on the at least one load map, for interpreting information 
contained within a load map and for generating time valued requests to the server 
based on available throughput arid informational requirements, and 

a cache manager that merges the information to organize the structured 
10 information, for use by the client 

10. The system of claim 8, the cache manager further including storage means to 
store at least the information associated with a pre-load operation. 

11. Thesy^temof claim 10, wherein the c^he n^^ 

block of the information from the storagb means, if the block is available, and 
15 requests a block from the servo:, if the block is riot yet available. 

12. The system of claim 8, further coiriprising a player which arrariges for the 
execution of the structured information. 

13. A method for providing multiple levels of support for executing over a 
computer network a program having blocks of executable code, comprising 

20 providing, for a plurality of netWdrk performance levels, a plurality of load 

maps associated with respective ortes of said network performance levels and having a 
list of sections of executable code of the pi^g^un ordered according to the expected 
priority of acCesfsf of the executable code by the program, 

determining a network performance level available through the network to a 
25 client, ' .: 

selecting a load map as a function of the network performance level available, 

and 

allowing the client to request sections of program aicco^ 
map selected. 

30 14. A method accdfdinjg to claim 13, further including 
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processing the program to generate the plurality of load maps. 

15. A method according to claim 14, wherein processing the program includes 
determining for a respective network performance level a preload list representative 
ofa series of sections of executable code that are to be transmitted over the network 

5 prior to execution of the program. 

1 6. A method according to claim 14, wherein processing the program includes 
monitoring execution of the program to determine a sequence of block fetches for 
moving sections of executable code into computer memory and cache during program 
execution. 

10 17. Amemodaccordmgtoclaiml4,wheremgeneratmgm 

ordering the list to provide a delivery sequence for scheduling delivery of sections of 
executable code over the network to me client 

18. . Amethodaccord^ 

generating the ordered list to schedule traiisnusaon of executable code over the 
network during aperiod of low network activity during program execution. 

19. Amemodaccordingfocl^^ 

level includes launching a player program at the. client capable of exchanging 
information with a remote server for determining the available network bandwidth. 

20. Amemod according to claim 13, wheremdeterminmg a network performance 
level includealaunclungapkyer programs 
information with a remote server for taennihing network latency. 

21. Amemodaccordingtoclaim 13,wheremdetenmnmga 
level includes detennining cache memory available at the client 

22. * A memodaccordmgtoclaim 13, wheiem selecting a load map includes 
comparing a network performance level to a threshold level and preceding to selecting 
of a load map as a function of the comparison 

23. A mewod awarding to clata ^ 
selecting one of a plurality of servers for transmitting information 

24. • A method for providing multiple levels of support for executing over a 
computer network apmgram having blocks of executable code, comprising 

' ... -29- - ' 
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. providing a file system ri^nageinent process for monitoring file access 
operations of a computer program executing within an application memory space, 
executing the program, 

employing the file system management process, while the program is being 
5 executed, for determining a sequence and a timing pattern with which blocks of 
executable code are loaded into the application memory space, and 

processing the sequence and timing pattern to generate a load map 
representative of a sequence and timing pattern for transmitting blocks of executable 
code over the network. 
10 25. * A method according to claim 24, wherein processing the sequence and timing 
pattern includes generating a plurality of load maps each associated with a respective 
level of network performance. 

26. A method according to claim 24, wherein executing the program includes 
executing the program a plurality of times to identify a plurality of optional sequence 

15 and timing patterns for loading blocks of the executable program into application 
memory space. 

27. A method according to claim 24, wherein generating the load map includes 
processing the sequence and tuning pattern to determine a preload factor 
representative of a number of blocks of executable code that are to be transmitted for 

20 enabling execution of the program over the network. 

28. A process according to claim 24, wherein generating a load map includes 
processing the sequence and timing pattern to identify periods during program 
execution available for transmitting additional blocks of executable code. 

29. A process according to claim 28, including determining probabilistically the 
25 additional blocks of executable <x)de to dehver d^ei: the network, 

30. A process according to claim 24, wherein processing the sequence and timing 
pattern includes collecting information representative of blocks of executable code 
requested from a remote site and adjusting the lda(d map as a function of the collected 
informatioa 
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31. A process according to claim 24, fiatber including adding trigger controls, 
within the generated load map for controlling post-load execution on a client based oi 
programs file accesses. 

32. A process according to claim 24, further comprising 

providing a map reader process for execution on the client and for reading the 
load map to detamine a sequence for requesting blocks of executable code from a 
remote server. 
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